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I. introduction 



The advent of computer technology during the previous 
two decades has affected virtually every aspect of govern- 
ment and private industry. As technological advances fester 
the availability of complex systems at lower prices, the 
integration of computer systems with governmental ar.d indus- 
trial processes is accelerated. Applications of computer 
systems range from relatively routine data processing tastes 
such as payroll, accounting packages, and inventory control 
to intricate scientific systems controlling space flights 
and decision support systems assisting managers in resolving 
unique problems. 

The pervasiveness cf this technology has created many 
new issues for management concern at all levels cf govern- 
ment and industry. Among these issues is the subject of 
security. As systems become more and more complex, organi- 
zations which utilize them are becoming more and more depen- 
dent upon them. This relationship is forcing 

computer-center management to devote efforts toward improved 
security in all areas: hardware; software; communications; 
personnel; and administration [Baf. 1]. It is useful to 
consider exactly what we mean by the term "security" with 
respect to computer systems. According to Wylie, security 
is "a stats cf mind reached when one's assets are receiving 
apprepriate protection. Protection has three facets cf equal 
importance. Preventative techniques are applied to prevent 
the occurence cf threats. Detection techniques are applied 
to ensure that all threat occurences are registered. 
Finally, for every threat cccurer.ce there must be an appro- 
priate response." [Ref. 2] These definitions present a 
framework on which a computer system security plan may be 
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developed. It may net be possible to design a system which 
defeats every intrusion attempt. However, an adequate goal 
for many organizations might be to raise the cost cf unau- 
thorized cr illegal use of a system to an amount so high 
that it discourages any attempts. While this goal is being 
pursued with vigor today, contemporary literature is replete 
with examples of computer crime. The U.S. Chamber of 
Commerce estimates that if computer abuse grows proportion- 
ally with the number cf computers in operation, there will 
be roughly $160 million annual less by 1985 [Ref. 3], 

Government agencies at all levels and private enter- 
prises, especially banks, must be concerned with the threat 
of sabotage and disruption, not only theft. The financial 
institutions participating in the electronic fund transfer 
sytem (2FTS) in the U.S. handle amounts of money equal to 
the national debt every four days [Ref. 4]. The potential 
for economic disaster of enormous magnitude exists. The 
motivation to prevent large-scale penetration and disruption 
cf systems such as EFTS is providing impetus for security 
research . 

The need for computer system security is self-evident. 
The magnitude of the problem is enormous. Partial solutions 
to this problem are being addressed in all areas. For 
example, software houses have developed sophisticated data 
access control packages. Many hardware venders are 
including seme type of security-control feature in their 
products. The issue of computer security, however, is not 

confined to technical considerations alone. Management must 
become intimately involved in this area if meaningful 
progress is tc be made. A commitment by top management, 
clearly indicating tc the entire organization the emphasis 
that must be placed upon security, is necessary. Management 
at all levels must be involved with determining policy and 
implementing measures concerning the organization of a 
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computer security program, security administration, risk 
assessments, personnel practices, and back-up, recovery and 
disaster planning. 

The federal government, including both civilian and 
military agencies, is the largest user of ADP facilities in 
the ccuntry [Ref. 5]. Computer usage spans a vast diversity 
of applications such as World-Wide Military Command and 
Control System (WWMCCS) , Social Security System, communica- 
tions, federal payroll and accounting systems, etc. This 
immense usage has logically generated interest in the 
security cf these particular computer systems. In fact, the 
attention being devoted to the security of computer systems 
is so great that the Office cf Management and Budget estab- 
lished requirements in 1978 that, among other things, every 
agency inplement a computer security program. OME also 
defined a minimum set of controls to be incorporated into 
each agency's computer security program. [Ref. 6] 

Contemporary literature on computer security seems to be 
in agreement in expressing the view that the best approach 
to computer security is the "total systems" approach. 
Critical areas which must be examined include hardware, 
software, users, pr cgrammme rs, data, input/output documents, 
and procedures. Other facets of a system pertinent to a 
particular organization may also need to be examined. One 
element cf the "total systems" approach is the conduct of a 
risk assessment. 

What is a risk assessment? Many texts offer definitions 
which differ slightly in scope and degree. Perhaps the most 
concise and applicable is Peter 3rcwne's definition: "A 

risk assessment is an analytic process designed to quantify 
the DP (data processing) security required by an organiza- 
tion. It considers the threats to information and the loss 
that would occur if a threat were to materialize. 1 ' [Ref. 7] 
The results cf a risk assessment enable an organization to 
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consider solutions to security problems which are cost- 
effective. The solutions may either attempt to reduce the 
probability of threats, lessen the effects of various 
threats, cr aid in the recovery from a "successful" threat. 

An organization may be able to conduct its own internal 
risk assessment if personnel assets are available. 

Specialists in computers, security, finance, personnel and 
operations will he required. Contracts may be utilized with 
one of several commercial companies organized to conduct, or 
to provide limited assistance, in risk assessments. Chapter 
Three will address this issue in depth. Of course, the 
active participation cf management is crucial. 

A risk assessment is a dynamic concept. It should be 
revised periodically to account for any changes in equip- 
ment, software, operating procedures, cr any different 
element which might affect the overall security of the 
system. In particular. Naval activities with computer 
systems are required to update their risk assessments at 
least every five years [ Ref . 8]. 

The federal government, as wall as business enterprises, 
must approach the security problem in an economical manner. 
The risk assessment provides a logical framework to conduct 
a rational analysis. Management must provide guidelines to 
reach answers to the following questions: 

1) What are the specific results required; how much 
security is required? 

2) What is the proper balance between security program 
ccst and potential benefits? 

3) When tradeoffs car. be made between protection and 
recovery, hew much effort should be expended on 
each? [Kef. 9] 

Obviously the minimum amount cf security needed is to 
protect tbose items that are required to keep the organiza- 
tion operating. The security manager should incorporate 
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into ths security plan those functions which are supports! 
ty computer facilities and essential to the continued opera- 
tion cf the organization. Additional elements may also be 
protected if it is economically feasible for the organiza- 
tion. A cost-benefit analysis may be applied to the 
decision-making process concerning additional security 
measures. 



In a risk analysis situation, it is necessary to iden- 
tify and assess the degree of threat against the computer 
resources cf the organization. Ike degree of threat may 
determine the need for protection of some asset. The amount 
and cost of effort tc be expended in examining particular 
threats should be proportional to the potential loss caused 
by such threats. Threats can usually be grouped into one or 
mere cf the following categories: 

1) natural hazards and accidents such as fire, ear + h- 
guakes, hurricanes, etc. 

2) internal accidents and breakdowns such as programmer 
and operator errors, hardware failures, etc. 

3) violent intentional actions such as sabotage, 
strikes, etc. 



4) ncn-violsnt intentional actions such as fraud, 
embezzlement, and theft, 10] 

The potential loss associated with each threat must also 
be examined . Some consistent quantifying standard must be 
applied to each threat so that comparisons between losses 
can be made. Similar to threats, losses may also he grouped 
into four general categories: 

1) delayed processing- the expense incurred when a 
computer application is not processed on time . 

2) less cf data processing assets- these are the orga- 
nizational assets in the custody of the data processing 
unit. Data are the most valued assets and loss cf data 
may cause irreparable harm. 
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3) less of organization assets by means of computer 
application s- when assets such as accounts receivable, 
negotiable securities, etc., are controlled by a 
computer, they are vulnerable to fraud and manipula- 
tion. 

4) loss of data confidentiality- disclosure of personal 
or proprietary data to unauthorized persons can cause 
economic loss, dilution of planning efforts, loss of 
employee morale, and legal action. [Ref. 11 ] 

The potential threats and the losses associated with each 
threat must be considered together. Each pairing of threat 
and less should be ranked according to their impact upon the 
organization. After this ranking has been developed, the 
process of examining cost- ef f ective countermeasures can be 
stud ied . 

This chapter has provided an overview of the nature of 
the computer security problem today. In particular, the 
concept of risk assessments has been introduced and its 
potential benefits to organizations have been considered. 
The subject of risk assessment and related ideas will be 
addressed in greater detail in later chapters. Chapter Two 
will detail the history and evolution of risk assessment 
requirements within the Department of Defense and the 
Department of the Navy. Chapter Three will examine various 
points which must be considered when an organization is 
deciding whether to do an "in-house" risk assessment or to 
contract this function with a commercial company. A general 
framework for conducting a risk assessment at the Naval 
Postgraduate School will be discussed in Chapter Four. The 
framework will be based upon the guidelines promulgated in 
OPNAVINST. 5239.1A. Chapter Five will examine how to 
design a decision support system to assist management in 
conducting a risk assessment. Basic design modules will be 
presented and some particular problems associated with data 
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base manage ment will be considered. The field of computer 
security in general, and risk assessments in particular, has 
advanced to such a degree that several companies new offer 
automated risk assessment systems. A brief consideration of 
these systems and a comparison of their attributes vis-a-vis 
manual systems will also be presented in Chapter Five. The 
final chapter will summarize the pertinent points covered in 
this thesis. Some conclusions will be drawn about the state 
of risk assessments in the aodern organizational environ- 
ment. Lastly, some recommendations to improve the effective- 
ness and efficiency cf the risk assessment process will be 
presented . 
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II . DEPARTMENT OF DEFENS E/D EPA5TM ENT OF THE N AVY DI3 ECT IVES 



A. GENERAL 

From the outset, the Federal Government has beer, a 
pioneer in the development of advanced computer systems. 
"The first successful large scale data processing installa- 
tion was made in the early fifties at one Census Bureau, and 
the initial impetus toward programming languages for busi- 
ness applications came from Department of Defense support of 
the COBOL programming language in the sixties" [Ref. 12]. 
From that pcint cn, the rapid growth of computer technology 
and the government’s reliance on accurate computing systems 
rose at an exponential rate. Poor accounting and managerial 
control practices, however, have brought about extreme inac- 
curacies in the data pertaining to computer hardware and 
software inventories held by the Federal Government. In 
1976, estimates of the amount of money spent on data 

processing were decidedly vague. "The General Accounting 
Office (GAC) was able only to bracket Federal Data 
Processing spending as between 33 billion and $10 billion 
annually. Mere recently, the Office of Management and Budget 
(OMB) has cited a figure of $5.5 billion, and the General 
Services Administration (G S A) has estimated the cost of 

software development and maintenance alone at $2.2 billion." 
[Ref. 12] A large percentage of these expenditures were 
attributed to the DCD. In 1931, the number of installed 
computer systems was estimated to be around 15,000, while 
the number of personnel working in the computer field was 
estimated at 100,000 [Ref. 12]. These figures, however, are 
gross approximations. 
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Sines ths science of computer technology was a relatively 
new phenomenon at the time the government began to explore 
its possibilities, the development of government computer 
systems was done in a rather piecemeal fashion, with little 
regard to the managerial aspects of designing and imple- 
menting computer systems. The emphasis was on buying/ 
developing and getting the systems into operation as fast as 
possible in order to show that a functional entity had 
resulted from all the monetary and personnel resources that 
had been expended. As a result of this mismanagement (or 
rather non-management) , government agencies were faced with 
computer systems that were inflexible, inaccurate, and 
subject tc rapid obsclasenca. Ths public outcry over the 
amount of tax dollars spent on mismanaged computer resources 
led the Federal Government to issue policy directives 
addressing computer management from the initiation of 
requirements analysis to final test and implementation. 

B. GCV2HNMENT CONCEBNS 

At about this same time, there was a growing concern 
over the security vulnerabilities inherent in these new 
computer systems. Although hardware and software technology 
had been progressing at a rapid rate, little consideration 
had been given to computer security technology. However, 
with the Ercoks Act cf 1965, the Office of hanagement and 
Budget (CUE) had been assigned responsibilities for the 
oversight and policy-making functions applicable to computer 
systems development and acquisition. Thus, "in 1972, — 0M3 
urged private industry -- hardware manufacturers, software 
houses and related service industries — to make greater 
capital investments in computer security. At the time, the 
Federal Government was concerned that its inability to 
protect data in computer systems -- except at very great 
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expense -- was limiting its ability to realize the benefits 
cf technology." [Ref. 13] In December of that same year, 
the Department of Defense issued DDD Directive 5200.23 enti- 
tled "Security Requirements for Automatic Data Processing 
(ADP) Systems". The purpose of the directive was to estab- 
lish "uniform policy for protecting classified data stored, 
processed, or used in, and classified information communi- 
cated, displayed, cr disseminated by an Automatic Data 
Processing (AD?) System" [Ref. 14], Although DOD 5200.28 
does not directly address risk assessments, it does require 
that the heads of DOD components provide for the appointment 
of an ADP Security Officer, who will later play an important 
role in conducting risk assessments for Navy computer 
facilities. 1 

In the mid-1970's, 0MB became even more concerned with 
encouraging the growth of computer security technology since 
the Privacy Act of 1874 set "forth a series of requirements 
governing Federal agency personal record-keeping practices" 
[Ref. 15]. These requirements increased the need tc provide 
security for the personal data maintained in Federal 
computer systems. 

C. LEGISLATION 

The Brooks Act also assigned other agencies responsibili- 
ties for contributing to the Federal ADP Programs. The 
National Eureau of Standards (NBS) , under the Secretary of 
Commerce, was tasked with providing "leadership, technical 
guidance, and coordination of government efforts in the 
development of guidelines and standards" [Ref. 19]. in 



1 The terms "Risk Analysis" and "Risk Assessment" can be 
used interchangeably. While early government directives used 
"Risk Analysis", it is now more common to use "Risk 
Assessment" . 
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areas pertaining to ADP and ADP Security. The basic philo- 
sophy behind the NBS work in ADP Security was reflected in 
Federal Information Processing Standards Publication (FIPS 
PUB) 31 of June, 1974: "Data confidentiality and computer 

security are dependent upon the application of a balanced 
set cf managerial and technological safeguards. Within the 
context cf a total security program, the NBS is pleased to 
provide guidelines for ADP Physical Security and Risk 
Management avilatle for use by Federal agencies" (Ref. 19]. 

The concept of Risk Ma nag ement was introduced at this 
time to provide federal agencies with guidelines for 
applying management principles to the ris*s associated with 
the acquisition cf hardware and software. Although FIPS PUB 
31 specifically addresses physical security programs, it 
also touches upon procedural aspects, contingency planning, 
supporting utilities, computer reliaoility, disaster prob- 
abilities, security awareness programs, and risk analysis 
methodologies. This publication was one of the first to 
provide specific recommendations on implementing comprehen- 
sive computer security programs. It is important to note, 
however, that its contents were strictly composed of recom- 
mendations and guidelines - they did not constitute a 
government directive mar.d a ting computer security require- 
ments on government agencies. The publication was edited by 
Susan K. Reed of the Systems and Software Division of NBS. 
She later authored a government document on conducting risk 
analyses which would be included as an addendum to DOD 
5200. 28-M, the Department of Defense ADP Security Manual. 
This manual will be discussed in more detail in a subsequent 
section . 

It is interesting to note that FIPS PUB 31, published in 
1974, covers in great detail those security practices that 
are advocated by more recent publications. Unfortunately, 
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the publication has been overshadowed by current directives 
that dictate what must be done but not how to dc it. For 
example, conventional risk assessments require an analysis 
cf the potential threats to an AD? facility caused by wind- 
storms, hurricanes, and tornadoes. Such information could 
conceivably be obtained from the National Weather Service, 
but it is already provided in FIPS PUB 31. In Key West, 
Florida, tc be specific, the annual probability that a 
hurricane will occur is 13% [Ref. 20]. This figure could be 
used as direct input to the threat analysis form for the 
current ECD-advocated risk assessment methodology. 

Tc start a security program, the FIPS encourages all 
government agencies tc "perform a preliminary risk analysis 
to identify major problem areas and select interim security 
measures as needed to correct major problem areas" 
[Ref. 21], The idea behind this is that, since computer 
security is an ongoing process, the most obvious security 
problems should be handled in an expeditious manner - agen- 
cies need net and should not wait until a comprehensive risk 
assessment has been completed prior to tackling the serious 
security problems. In the meantime, a preliminary assess- 
ment should be done to help isolate those problems. 

The actual risk assessment methodology presented in the 
FIPS is a scund one. It gives an excellent overview of the 
means by which a riok. assessment may be conducted, complete 
with charts, tables, and figures that the user may apply in 
calculating the final Annual Loss Expectancy (ALE) value. 
However, the publication is somewhat weak when it comes to 
describing the format or layout cf an agency's actual risk 
assessment document. 
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D 



DEFINITION S 



Before going into the specific risk assessment method- 
ology outlined in the FIPS, it is appropriate to define 
certain terms which are common to most, if net all, 
government-endorsed risk assessment methodologies : 

THREAT -an overt or covert activity which may cause 
less or damage tc a computer facility; 

LOSS -the potential for being deprived of computer 
assets or services; 

VULNERABILITY -the weakness inherent in a computer 
system, which makes it susceptible to loss or damage; 

ANNUAL LOSS EXPECTANCY (ALE) -an estimate of the amount 
of money that a computer facility could potentially 
lose in a year if threats against the facility were 
realized. 

E. FIPS PUB 31 METHODOLOGY 

The PIPS methodolgy is basically a three-step process : 
1.) Make an estimate of the potential losses tc which the 
computer facility is exposed; 2.) Perform an analysis of the 
threats which may be made against the facility; and 3.) 

Combine the estimates of potential loss and probability of 

less tc produce an ALE value. 

1 • Esti mat ing Less 

Step one, estimates of potential losses, is to be 
done in terms of five distinct categories : "(1) physical 

destruction or theft of physical assets; (2) loss or 

destruction of data and program files; (3) theft of informa- 
tion; (4) theft of indirect assets; and (5) delay or preven- 
tion of computer processing" (Ref. 21]. The end products of 
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this procedure are an iaent if ication of the computer facili- 
ty's assets and dollar values for loss estimates. 

Cf the five categories listed, the first is undoub- 
tedly the most straightforward. Replacement costs for such 
items as hardware, communications equipment, supplies, and 
the building itself should be entered into the command’s 
inventory files as required by G SA. Unfortunately, many 
federal agencies have neglected to maintain inventory files 
over the years. One of the fringe benefits of a risk 
assessment is that such inventories must be generated, thus 
enhancing a command's resource management capabilities. 
Once these inventories have been made available, the esti- 
mate cf less for a particular piece of equipment corresponds 
to its replacement cost. For example, if a high-speed line 
printer costs $5000, then its loss estimate would be the 
same - the command has the potential for losing $5000 if the 
printer were to be destroyed or stolen. 

In the second and third categories, less or destruc- 
tion cf data and program files and theft of information, a 
great deal cf ambiguity occurs. The question which must be 
answered is : What is the value of the data contained in the 
computer system ? This is a question which has received a 
great deal of attention, in recent years. The Commander, 
Naval Data Automation Command (COMNAVDAC) , spent a signifi- 
cant amount cf time and money in trying to bring the ques- 
tion of the value of data into perspective. Seme 
consideration was given to standardizing data value based or. 
the number cf lines cf cede and/or security classification. 
A single line of code in a 100-line program file might be 
valued at $10, for example. The loss or destruction cf the 
file would thus contribute $1000 to the agency’s ALE. In 
essence, it would cost the command $1000 to reconstruct the 
file. In a similar manner, a word of SECRET or TOP SECRET 
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cede, if compromised or stolen, might be valued at $100 and 
$200 respectively. Ey standardizing these values, computing 
the ALE for most types of computer software would be a 
simple matter of mathematical calculation, with lines of 
code (the amount of money it would cost a programmer to 
reproduce the code) being an absolute value, and classified 
code representing a relative value. In theory, such methods 
have a sound basis. In practice, however, the application 
cf such methods has proven to be rather unrealistic. In 
fact, CCMNAVDAC has recently abandoned its attempts tc 
provide for standardization in favor of more practical 
metheds. 

"If the ADP system is used to control other assets 
such as cash, items in inventory, or authorization for 
performance of services, then it may also be used to steal 
such assets." [Ref. 22]. These assets are known as indi- 
rect assets, and their loss estimate corresponds tc the real 
value cf the asset. 

In estimating the potential less caused by the delay 
or prevention cf computer processing, several consider ati ens 
must be addressed. Some losses may be estimated in a rela- 
tively straightforward manner. Obvious examples involve a 
failure to process payment checks promptly, thereby 
preventing the exercise of a prompt payment discount under a 
procurement contract, or delays in an inventory system which 
may lead to idle manpower at a warehouse [Ref. 22]. In a 
situation where a computer facility functions as a service 
agency, the loss estimate would be based on the revenues 
lost as a result of the customers being denied access tc the 
computer system. On the other hand, "...in those situations 
where a delay would more or less halt operations of an 
agency, .. .use the daily operating cost cf an agency as a 
rough rule-of-thumb estimate of the cost of delayed 
processing" [Ref. 22]. 
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In general, there are time ranges or limits within which 
loss estimates will differ. If service is denied but the 
system can be brought back up witain a reasonable amount, of 
tame, it is possible that no loss will be incurred during 
that time period. However, after a certain period of time 
during which the computer system has not been returned to 
service, losses will be incurred, and in general, such 
losses will grow in proportion to the duration of the delay. 
The FITS PUB stresses the importance of establishing this 
"maximum *nc loss’ delay time and an estimate of the median 
time to reconstruct the ADP facility after total destruc- 
tion" [Ref. 22]. Once these time/cost boundaries have beer. 



TABLE I 
Loss Exposure 



Task 


Loss of 
Data 


Theft of 
Info . 


Theft of 
Assets 


Delayed 

Froc^ssin 


C 


Yes 


Ho 


No 


Extreme 


B 


Yes 


Yes 


Yes 


Moderate 


E 


Me 


Yes 


Yes 


Moderate 


T 


Ho 


Yes 


Yes 


Low 


C 


NO 


Ho 


Ho 


Very Low 



i i 



made, than the time period can be divided into various 
ranges and less estimates can be assigned accordingly. 



After conducting 
losses, the task 
collected data in 



a preliminary estimate of all potential 
might be simplified by presenting the 
tabular form, as shown in Table I 



extracted from FIPS PUB 31. 
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TABLE II 

Sources for Threat Information 



Thr eat 



Sources of 
Info r matio n 



F 2 . T9 



F lcod 

Earthq uake 



Windstorm 



Fewer Failure 



Air Condi- 
tioning Failure 

Ccmmunica- 
tiens Failure 



ADP Hardware 
Failure 



Intruders , 
Vandal s, etc. 



C empro misi ng 
Fmah at ions 



Internal Theft 
or misuse 



Building fire mar- 
shal ana local fire 
department 
Army Corps c-f 
Engineers 
National Earth- 
auake Information 
Center 

National Oceanic 
and Atmospheric 
Administration and 
local National 
Weather Service 
Office 

Building Engineer 
and local public 
utility 

Building Engineer 
and air condi- 
tioning vendor 
Federal Tele- 
communications 
System, building 
and local telephone 
comoany 

Hardware vendors 
and Federal Supply 
Service 

3uilding manager, 
security director 
and the Office of 
Federal Protective 
Service Man- 
agement, GSA. 
Hardware vendors 
and the Office of 
Federal Protective 
Service Man- 
agement, GSA. 

System Design, In- 
ternal Audit and 
Personnel Division 
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2 . 



Evaluating Threats 

In proceeding with the second step of the risk 
assessment, that of evaluating the threats against the ADP 
facility, the ADP Security Planner (is. the person respon- 
sible for conducting the overall risk assessment) should 
solicit the help of fire marshals, hardware vendors, ether 
government agencies, in house personnel, and/or any agency 
or person who might contribute inputs to a threat evalua- 
tion. Table II provides a list of sources of information 
for different categories of threats. 



Although the FIPS gives lit 
specific numerical figures to use in 
does provide specific guidance on as 
abilities. Figure 2.1, for example, 
the United States, gives the user a 
term hazards caused by earthquakes. 



tie information on the 
quantifying threats, it 
tsrmining threat crcb- 
a seismic risk map of 
rough idea of the long- 
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3. Calc ulatin g t he Ann ual Loss E xp act anc y (ALE) 

The final step in the risk assessment process 
itself, although follow-on action is understood, involves 
the determination of the ALE. This can be accomplished (and 
most readily understood) by constructing a matrix of Threats 
and the losses which might be associated with them. Table 
III shows a computation for estimating the expected losses 
that might be caused by fire damage. 

Construction of such a table is a common procedure 
in operations research and management sciences where the 
objective may be to minimize losses (as in this case) or 
maximize profits. The occurrence probabilities shown (.10, 
.05,. 005) may be derived by analyzing the facility's fire 
safety precautions, a procedure for which the FIPS PUS qives 
detailed guidance. 

The dollar amounts for loss may be computed as 
described earlier in the chapter. Once these figures have 
been made available, estimates for the total potential less 
and tbs annual loss for each category can be calculated by 
multiplying the occurrence probability by the loss figures. 
Similar tables can be constructed for natural disasters such 
as earthquakes, tornadoes, volcanic eruptions, floods, and 
others. 

Open completion of the estimation of the ALE for all 
categories cf less, the security manager should have a 
clearer understanding of the coupling of threats and losses 
within his facility. He is then in a position to prioritize 
his work in the area of computer security countermeasures. 
In general, remedial measures should be applied to these 
areas in which the loss potential is the greatest. The end 
result, then, of the risk assessment process is a cost- 
benefit analysis of expending funds towards the "securing" 



28 



TABLE III 

Estimating Fire Loss 









Fir* Description 








Minor Fir* 
la ADP Am 


Major Fire 
In Bide. 


Total 
Low Fir* 




Occurrence 

Probability 


<H0 


0.06 


.0005 




Building Damage 


no, ooo 


noaooo 


33.700,000 


3 


ADP Hardware 


50,000 


10,000 


2 aoo,ooo 




General Equip. 


5,000 




285,000 


si 


Supplies, etc. 


10,000 




130,000 




Task D — Delay 






35,000 


Task E— Delay 


5,000 


7,000 


100,000 


5 


Task F — Delay 


12,000 


20,000 


250,000 




Pile Reconstruct 


5,000 


— 


85,000 


Total potential ion 


07,000 


137,000 


6,683,000 


Annual loss 


3 9,700 


3 6,350 


3 3^42 




of a specific computer security weakness. If, for example, 
the ALE fcr building damage cajsed by fire is $ 9,700 , the 
agency should be willing to spend up to that amount in 
providing remedial measures to lessen that loss potential. 
The risk assessment will thus provide the security manager 
with the ammunition he needs to get top management support 
on funds fcr security countermeasures. 

The preceding synopsis of the FIPS methodology might seem 
to be, as presented, a relatively straightforward process. 
However, the FIES EUB clearly states, "...this is net an 
exact science. Indeed, it is quite likely that one will 
have to reappraise threats and losses more than once, 
concentrating on the areas initially identified as most 
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critical, before the less expectancy estimate reaches a 
satisfactory level of confidence." [Ref. 23] 

The level of detail provided fer the above FIPS PUB meth- 
odology will serve as a point of reference for descriptions 
cf subsequent metho dclcgies . Other risk assessment metho- 
dologies will be discussed in terms cf how they differ from 
the ens described in FIPS PUB 31. 

F. SUBSEQUENT GOVERNMENT DIRECTIVES 

Shortly after the release of FIPS PUB 31, the Privacy Act 
cf 19*74 was enacted. OMB Circular A-108, distributed six 
months later, was written to assign responsibilities for the 
security cf the personal records maintained by Federal agen- 
cies. Under this directive, the term "system of records" 
was defined as "...a group cf any records under the control 
cf any agency from which information is retrieved by the 
name of the individual or by soma identifying number, 
symbol, or other identifying particular assigned to the 
individual" [Ref. 16]. Since computer and word processing 
systems are perfect vehicles for data storage and retrieval, 
it was and is only natural that they would be used for the 
maintenance of personal records. A-108 further mandated 
that reasonable administrative, technical, and physical 
safeguards are established to ensure that personal records 
are cnly disclosed to those who are authorized to have 
access tc them [Ref. 17], This implies that security coun- 
termeasures must be in effect for ail federally-cwned 
computer systems maintaining personal data. The directive 
also required that the GSA "revise computer and telecommuni- 
cations procurement policies to provide that agencies must 
review all proposed equipment and services procurements to 
assure compliance with applicable provisions of the Act" 
[Ref. 18]. This was the first of many government directives 
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r eq u ir i nq that federal agencies address security issues in 
their computer development ana acquisition plans. However, 
outside of FIPS PUB 31, the distribution and knowledge of 
which was very limited, the Federal Government was slew to 
document specific policies and procedures for implementing 
computer security programs. 

Finally, three years later in July, 1978, OMB Circular 
A-7 1 , entitled "Security of Federal Automated Information 
Systems", was approved for distribution. Ir. general, the 
purpose cf A-7 1 was to promulgate "policy and responsibili- 
ties for the development and implementation cf computer 
security pregrams by executive branch departments and agen- 
cies" [Bef. 24], This circular documented the requirement 
that periodic risk assessments be conducted by each federal 
agency operating a computer facility. Although A-71 
provided no guidelines on how to conduct a risk assessment, 
it did require that a risk assessment be carried cut or 
revised under any of the following conditions : 

1. ) prior to the approval cf design specif icaticns fer 

new computer installations; 

2. ) whenever there is a major change to the physical 

facility, hardware or software; or 

3. ) at periodic intervals of time, not exceeding five 

years, if no risk assessment has been performed dur- 
ing that time. 

[Bef. 25] 

This directive had serious consequences for all federal 
agencies. For most agencies, the third condition was the 
one under which the risk assessments would be conducted. 
Those agencies which had yet to perform a risk assessment 
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interpreted the condition as meaning chat they had a five- 
year deadline on the requirement. Unfortunately, this 
slowed response from many federal agencies. 

Tc promulgate the requirements of A-71, the Department of 
the Navy issued OPNAVINST 5239.1 in April, 1979. This 
instruction specified the A-71 requirements for all DON 
activities. Although the instruction did little to augment 



the policies provided by A-71, 
activities operating computer 
Security Officer who would be 
a risk assessment would be c 
Two relevant enclosures tha 
CPNAVINST 5239.1 were DOD 5200 
Procedures fcr Implementing, 
Evaluating Secure Kescurce-Sha 
of guidelines for conducting 
edited by Susan K. Seed. Th 
ADP Security Manual, provide 
securing computer systems - it 
ments; the latter, however, 
framework fcr conducting risk 
mors in facilitating the secur 
the risk assessment model th 
proposed. The technique pre 
similar tc that presented in 
mathematically-oriented model, 
released in August, 1979, as 
Automated Data Processing Risk 

G. FIPS FOE 65 METHODOLOGY 

In general, FIFS PU3 65 
performing a risk analysis, d 
ment necessary and presents pr 



it aid require that all DON 
installations appoint an AD? 
responsible for ensuring that 
onducted on a periodic basis, 
t were included as part of 
.28-M entitled "Techniques and 
Deactivating, Testing, and 
ring ADP Systems", and a set 
risk assessments which was 
e former, constituting the DOD 
d stan dar dized guidelines for 
did not address risk asssss- 
provided an excellent generic 
assessments. It’s merit was 
ity officer’s understanding of 
an in the actual methodolgy 
seated oy the methodology is 
FIPS PUB 3 1, but is a more 
These guidelines were later 
FIPS PUB 65, "Guideline for 
Analysis". 

"explains the reasons for 
etails the management invclve- 
ocedures and forms to cs used 
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evaluation cf 



for risk analysis and cost effective evaluation cf safe- 
guards" (Ref. 26], Unlike FIPS PUS 31, this NBS publication 
gives no guidance on estimating specific loss prc facilities 
(ie. there are no seismic risk maps or tables with hurricane 
probabilities for various regions) , but it does provide a 
better and more detailed explanation of the quantitative 
measures and forms required for a risk assessment. In 
short, FIFS PUB 65 covers the ambiguities present in FIPS 
FUB 31. The two in combination provide a powerful framework 
under which a viable risk assessment can be conducted. 



Like most methodologies, the one advocated by FIPS PUB 65 
recommends that a preliminary security analysis be performed 
in order to identify a computer installation's assets, 
threats, vulnerabilities, and thus, the facility's security 
posture. Three specific products will result frcm this 
preliminary analysis : 

1. ) a list of asset replacement costs; 

2. ) a list of threats to which the facility is vulner- 

able; and 

3. ) a list of existing security measures. (Ref. 27] 

These products, once assigned quantitative measures, will 
form the basis for the computation of the ALE (s) . 

The next step in the FIPS methodology is to quantify the 
measures for impact and the frequency of occurrence for 
threats. The impact cf an event is defined as the exact 
amount cf damage it could cause, while the frequency of 
occurrence refers tc the exact number of times the event 
could occur. (Ref. 28] The common denominator selected for 
the measures is monetary value, and a year is the time 
period against which frequencies of occurrence will be 
assessed. To simplify such quantitative measures, estimates 
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for impact and frequency are rounded off to factors cf ter. 
The range cf measures for both categories is shown in Table 

IV. 



TABLE IV 

Orders of magnitude of Estimated Impact and Frequency 



I MPACT ; 



$1000 
$ 10 , 000 
$ 100,000 
$ 1 , 000 , 000 
$ 10 , 000,000 
$ 100 , 000 , 000 

FREQUENCY: 

Once in 300 years 

Once in 30 years 

Once in 3 years ( 1000 days) 

Once in 100 days 

Once in 10 days 

Once per lay 

10 times per dav 

100 times per day 



The FIES emphasizes that rounding off the figures will 
not have a significant effect on the overall ALE. The rele- 
vance lies in orders of magnitude rather than in absolute 
figures. Thus, "there will be nc significant difference in 
the overall exposure whether the damage from a certain event 
is estimated at $110,00 0 or $1 45,000. .. (or) .. .if the 
frequency of an event is expected to be twelve times a year 
cr thirty" [Ref. 29], Once the impact and frequency 
measures have been determined, the ALE can be readily calcu- 
lated using the following formula : 
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LOSS = IMPACT (I) X FREQUENCI OF OCCURRENCE (F) 



Tc use this formula, however, it is first necessary to 
index the impact (i) and the frequency (f) measures from 
Table IV. The resulting indices are shown in Table V. 



TABLE V 

Table for Selecting of Values of i and f 



If the estimated cost impact of the event is 



$ 10 
$1 00 
$1000 
$ 10,0 00 
$ 100,0 00 
$ 1 , 000,0 00 
$ 10 , 000,000 
$ 1 00 , 000,000 



1 9 ^ i 
let i 
let i 
let i 
let i 
let i 
let i 
let r 



1 

2 

3 

4 

5 

6 

7 

8 



If the estimated frequency of occurrence is 



Once in 300 years. 
Once in 30 years. 
Once in 3 years. 
Once in 100 days. 
Once in 10 days. 
Once per day, 

10 times per day, 
100 times per day. 



Is; 


c 

4. 


1 hr 


f 


let 


f 


let 


£ 


1st 


2 


lez 


f 


1st 




let 


f 



1 

2 

3 

4 

5 

6 

7 

8 



To use the indices in the previous equation, they must first 
be related to Impact (I) and Frequency of Occurrence (F) . 
Such relationships are expressed in the following equa- 
tions : 

i 

for Impact, I = 10 

(f-3) f 

for Frequency, F = 10 /3 = 10 /30G0 
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Thus, if the impact of. an event is estimated at $100 ( i=2 

from Table V) then I = 10^ = 10^ = 100. Similarly, if the 

frequency cf occurrence is estimated to be once per day 

f 6 

(f=6) , then F = 10 /3000 = 10 /3000 = 333. 3. 

Consider the following practical example, where the 
potential impact of a hurricane is $100,000 in damage to a 
computer facility, and the frequency for a hurricane is once 
in thirty years. The ALE would then be computed as fellows : 

IMPACT : $100,000 (i=5 ) 

I = 1 0^ = 100,000 

FREQUENCY : 1/30 years (f=2) 

2 

F = 1C /300 0 = . 0333 

LCSS: I x F = 100,000 x .0333 = 3,330 

Thus, the ALE resulting from a hurricane would be approx- 
imately $3,000. 

It is not necessary, however, re compute the ALE using 
these tedicus and cumbersome equations. The FIPS PUB 
provides figure 2.2 tc facilitate the process. The ALE for 
a particular event can then be feund at the intersection of 
the values estimated for impact and frequency. 

When all ALEs have been calculated, the FIPS PUB suggests 
that the approach tc the remainder of the task be done in an 
orderly and structured manner. In short, it recommends that 
"...the risk analysis task is better approached from the 
standpoint cf the data files, or applications systems, of 
which there is a finite number" [Ref. 30]. 
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$3 0k 


$300k 


$3M 


$30M 


4 




$300 


$3,000 
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$3,000 
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$300M 
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530M 


5300M 
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$300k 


$3M 


$30M 


5300M 
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Figure 2.2 Combined Hatrix of i, f, and ALE. 

In terms of such software considerations, the publication 
discusses three conditions which might result if a threat to 
a computer system were realized : DATA INTEGRITY (eg. 

destruction or unauthorized modif rca tions to data); DATA 
CONFIDENTIALITY (is . a compromise of classified data) ; and 
ADP AVAIIAEILITY (pertaining to the amount of time that a 
computer system can be returned to service after failure) . 

To provide structure and order to the recording of the 
risk assessment findings, the FIPS PUB supplies the work- 
sheet presented as figure 2.3 Such a worksheet might 
simplify the record-keeping aspect of the process, but it is 
only a suggestion - if used, it should oe formatted or 
tailored to an agency’s needs. 
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Figure 2.3 FIPS PUB 65 WORKSHEET 



On this particular worksheet., data files are listed sepa- 
rately, and arranged by application. Impact and frequency 
estimates and AL£(s) for each category of threat are then 
listed alongside the associated file. A comments column is 
provided to allow for an amplification of the figures shown. 
As an additional guide to using these work sheets, the PIPS 
FOB presents a practical example (for a small organization) 
of a complete risk assessment. 

The FIPS PUB attempt to structure the rrsk assessment 
process adds a degree of credibility to the overall method- 
ology. However, it is unreasonable to expect that the whole 
process can be carried out as a "cookbook" method. There 
are definite limits tc structuring such a task, particularly 
in areas such as identifying and estimating the threats 
against a facility. In short, "ADP risk analysis is a tech- 
nique which relies heavily cn the intuition, experience and 
technical knowledge of the team members" [Ref. 30]. 

H. CURRENT DIRECTIVES 

Approximately a year after the release of FIPS PUE 65, 
the NES distributed a ten-page document entitled "Risk 
Analysis Standard". The purpose of this document was simply 
to standardize the terminology and concepts behind the DOD 
philosophy for conducting risk assessments. It did not 
supply any specific guidelines or methodologies. 

Finally, in August, 1982, the DON approved and distri- 
buted OENAVINST 5239. 1A, a full and comprehensive manual 
describing the Navy's ADP Security program. A significant 
portion cf this manual addresses the approved DON risk 
assessment methodology, complete with forms and specific 
directions. The procedural aspects of this methodology will 
be presented as a practical framework for a risk assessment 
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that cculd be conducted at the Naval Postgraduate School, 
in Chapter 4. 

This chapter has described how the currently-approved DON 
methodology has evolved over the years. Figure 2.4 shews a 
time line of the events leading up to the distribution of 
CPNAVINST 5239. 1 A. 
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Figure 2.4 Time Line of Government Directives 



III. IN-HOUSE VS CjDN TRACT UAL SUPPORT 



A. GENERAL 

With the distribution of OMB Circular A-7 1 in 1 978 came 
the requirement that a "Risk Assessment.” (sometimes referred 
to as a "Sisk Analysis”) be conducted at each computer 
installation operated by a federal agency. While the risk 
assessment methodology currently recognized within the 
Department of Defense is a manual system, there are commer- 
cial software packages available, notably PANAUDIT by 
Pansophic Systems, which could facilitate the "number- 
crunching” aspect of risk assessments. Unfortunately, this 
particular software is only IBM-compatible, and thus has 
limited application to Navy computer systems. 



In the past few years, numerous government directives and 
guidelines cn methodologies for conducting risk assessments 
have teen disseminated. Many of these have resulted from a 
joint effort on the part of government and commercial 
industry. In 1977, in an effort to perfect a more concise 
methodology that could be applied to various sizes and types 
of computer systems within the Department of the Navy, 
COHN A VD AC let a contract with Systems Development 
Corporation (SDC) to develop and document such a method- 
ology. This contract, involving contractor support 
services, falls under the Policy/Program Review category 
outlined in NAV MATINST 4200. 50C. The justification for 
contracting cut such a service was undoubtedly a matter of 
the expertise held by the commercial marketplace. The 



result of the contract with SDC is contained in NAVDACINST 
5510.1, the Department of the Navy AD? Security Manual. 
While still in draft form, the distribution of this manual 
will serve as an excellent reference for those Naval agen- 
cies about to initiate a risk assessment. 

1 . The Need for Contr ac tual Sup p ort 

Many government directives pertaining to ADP 
Security provide guidance on the in-house personnel an 
agency must use to form their risk assessment team. Such 
personnel generally include representatives from ADP 
Operations Management, Systems and Applications Programming, 
Hardware Maintenance, Communications Engineering, Internal 
Auditing, and the Security Staff. Since a comprehensive 
risk assessment is a time-consuming process, diverting the 
services of these individuals from their normal duties could 
well create a hardship within their divisions or depart- 
ments. This potential hardship was recognized by personnel 
at NAVEAC who began to consider the possibilities of 
allowing for contractual support in conducting risk assess- 
ments. Although previous directives only discussed 

conducting risk assessments in terms cf using in-house 
personnel resources, NAVDACINST 5510.1 mentions that quali- 
fied contractors may be used with prior approval from 
NAVDAC. 

2 • A E rot ot yds for a C ontracte d Risk A ss essmen t 

In early 1980, personnel at the Fleet Numerical 
Oceanography Center (FNOC) in Monterey, California, began to 
have serious doubts about their ability to conduct an 
in-hcusa risk assessment. The computer configuration at 
FNOC, consisting of numerous large-scale mainframes, commu- 
nications networks and devices, minicomputers, and peri- 
pherals, was extremely large and complex. It would be very 
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difficult to spare the key personnel needed on the risk 
assessment team from their everyday duties. with this in 
mind, the ADP Security Officer at FNOC wrote to NAVDAC 
asking fcr guidance cn using contractor assistance. NAVDAC, 
which had teen giving this issue a great deal of thcugnt, 
decided tc use FNOC as a prototype for future contracted 
risk assessment efforts. To this end, NAVDAC offered to 
lend technical assistance, provide liaison with the 
contractor and other knowledgable government agencies, and 
oversee the entire process. The government agencies tc be 
involved (directly or indirectly) in the process are these 
shown in figure 3.1, which was extracted from NAVDACINST 
5510. IX [Ref. 33]. These agencies roughly parallel these 
which play a key role in federal acquisition policies and 
procedures. 

3 . Sta ndard izat ion in C ontract ed Bisk Assessme nts 

While the end result of this contract effort was to 
he a completed risk assessment, it was also serving as a 
standard against which future risk assessments cculd be 
conducted. Thus, as concerns arose during the project, 
NAVDAC documented them and considered ways in which the 
process cculd be enhanced and standardized. This study will 
briefly summarize the events that occurred during FNOC's 
risk assessment, shew how NAVDAC monitored and controlled 
the whole process, and describe how NAVDAC has streamlined 
the system tc facilitate contractor support cn any activi- 
ty's risk assessment. 

4 • Preliminary E fforts 

NAVEAC's first priority in assisting FNOC was to 
gather a pool of personnel whose technical expertise would 
facilitate the project. Tc this end, FNOC was provided a 
copy of NAVDACINST 5230. 1 A, "Procedures for Reguesting 
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Figure 3.1 DON/ADP security Organizational Relationships. 



Services from Navy Regional Data Automation Centers 
(NASDACs)' 1 . FNOC' s task was to generate a letter requesting 
technical support services from NARDAC, San Francisco. 
Included in this letter was information pertaining to 
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project title, requesting command, type of request, objec- 
tives, security classif ica tion, and funding. Identifying 
the source of the funding is an important consideration in 
requesting NARDAC services. "Commencing in fiscal year 1S82 
all Navy customers of a NAEEAC, except Navy industrial Fund 
Activities, will be supported on an entirely mission funded 
basis ... Onprcgrammed costs which cannot be accommodated will 
be subject of discussion between the NARDAC and the customer 
to determine if other means of funding are available" 
[Ref. 34]. In this situation, FNOC had budgeted $100K for 
the risk assessment project, and the NARDAC had no funds 
available. It was thus determined that FNOC would remit the 
$1Q0K to the NARDAC, who along with NAVDAC, would use the 
funds tc cover the costs of the government's technical 
support personnel and the contractor's fees. 

Cnee the method of funding had been determined, 
NAVDAC sent technical experts from the NARDAC, NAVELEX, and 
NESEA (Naval Electronics Systems Engineering Activity) to 
FNOC to discuss the program with ADP Security personnel. 
These personnel outlined the project and generated a docu- 
ment on FNCC's computer assets for use by the contractor. 
NAVDAC, in the meantime, was using inputs from this group to 
generate a plan of action and milestones that the contractor 
would be expected to follow. 



5. The Con tra ct 



NAVDAC handled all t 
and awarding the contract, 
negotiations, evaluation, 
available tc the authors, 
completed, the contract was 
Corporation (SDC). 



he requirements for negotiating 
The details, however, on the 
selection, and award were not 
After the negotiations had been 
awarded to Systems Development 
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Ey the time the SDC personnel arrived at FNOC, they 
had been in constant touch with the project manger at 
NAVDAC, and ware well aware of the tasks expected cf them. 
By interviewing personnel from all areas of FNOC's organiza- 
tional components, reviewing computer ccnf iguraticn sche- 
matics and documentation, penetrating computer security 
vulnerabilities and merging them with potential threats, 
they were able to assess FNOC's security posture and produce 
the required documentation and Annual Loss Expectancy (ALE) 
figures. 

6. Future Risk Assessment Contracts 



Since a risk 


assessment con 


tract will 


call 


study or analysis of 


the security 


aspects cf 


an e 


computer system, it 


will have to adh 


ere to t he 


re qui 



of NAVMA1INST U200.50C which addresses contractor support 
services. If FNOC's contract was any indication, future 
risk assessment contracts will undoubtedly exceed 35Ck, and 
thus will require legal review and approval by "...a level 
no lower than Flag or General Officer or individuals in the 
Senior Executive Service (SS S) " [Ref. 31]. 

In an effort to make FNOC and its parent command. 
Commander, Naval Oceanography Command (CNOC) , more autono- 
mous in contracting for future ADP security-related 
services, NAVDAC recently drafted a letter in which the 
subject line reads, "Automated Data Processing (ADP) 
Security Accredits tion and Contractor Assistance". This 
document will be invaluable to any Naval activity consid- 
ering contract support in completing a rrsk assessment. 
Although the information will not be afforded general 
distribution, NAVDAC is amenable to providing it when 
requested by a Navy activity. The several enclosures to the 
document constitute sample ADP security contracting docu- 
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meats, which as NAVDAC mentions, must, be tailored to 
specific tasking requirements and coordinated with the local 
Navy Eegicnal Contracting Center. NAVDAC's purpose rn this 
effort is "...an attempt to assure that Navy activities 
receive quality contractor ADP security reports and products 
for dollars invested" [Ref. 32]. 

Among the enclosures is a sample statement of work 
which may be tailored and included as part of an activity's 
Request fcr Proposal (RF?) , or in NAVDAC terms. Task Order 
or Task Bequest. The sample not only addresses risk assess- 
ments, tut also includes other ADP security areas which may 
be candidates for contractor assistance : Risk Assessment 

Planning, Contingency Plan Testing, and Security Training. 
It is the job of an activity's ADP Security Officer to write 
a task request based on the statement of work, describing 
the specific area of the work required. NAVDAC' s sample 
work statement has specific guidelines on the necessary 
wording, including a list of military publications to which 
the contractor must be responsive, and a list of required 
deliverables such as summary progress reports, schedule of 
performance, and contract financial progress reports. The 



sample work 


statement also 


includes an optic 


r. tc extend 


term of the 


statement of 


work. This will 


be renewabl 


prices staf 


ed by the con 


tractor and at the 


option of 


government. 


In addition, 


NAVDAC provides 


guidance cn 



Government-Furnished Equipment and documentation tha* an 
activity should be prepared to provide the contractor. 
Other documents NAVEAC has included as samples are : the 

Contract Security Classification Specification, detailing 
the security considerations and access requirements; 
Contractor Personnel Qualifications Statement, describing 
the minimum qualif ications expected of the contractor 
personnel assigned tc the project; Personal vs Nonparsonal 
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Services Questionnaire, a document used by the contracting 
officer to determine whether or net the solicited service is 
ncnperscnal; and the Contract Data Requirements List, which 
describes the required deliverables. These are all standard 
requirements for an RFP, but they have been uniquely 
tailored for a Risk Assessment application. 

As cf 28 July 1982, NAVDAC had approved six organi- 
zations to he included on the Bidder's Hailing List. These 
organizations and their qualifications are shown in figure 
3.2. At the time of this writing, three were qualified tc 
conduct risk assessments, but only two of these had DON 
approval. Two of the organizations listed were small busi- 
nesses. 

Each of these venders will be notified of a task 
request by the Contract Administration Office (CAO) . 

Vendors are required to pick up the task request within a 
week cf net ifica tion . NAVDAC refers to vendor responses as 

"Task Order Proposals" (TOPs). As is the case with standard 
RFPs , these are due at a specified time and date. 
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Figure 3.2 Small Business Matrix 



7. 



Propos al E valuatio ns and Selection 

Information required in a TOP for a risk asssssment 
includes "the number of man-hours by skill category by task 
and subtask, milestone dates, rraval costs, proposed pricing 
arrangements, personnel resumes, and technical approach" 
[Ref. 32]. The function of the activity's technical evalua- 
tion board, chaired by the ADP Security Officer, who is 
generally assigned as project manager, will be to evaluate 
these factors. 

NAVEAC stresses the importance of contractor 
personnel qualifications in evaluating ana selecting the 
contractor. Particular emphasis is placed on personnel 
weighting factors, with the result that factors other than 
cost may weigh heavily in the selection of one contractor 
over another. The list of qualifications for contractor 
personnel are quite comprehensive. Particularly important, 
especially for the lead person assigned by the contractor, 
is experience in computer center operations, ADP Sisk 
Assessment methods, system software generation, computer 
security, telecommunications security, and computer hardware 
and interconnections. A proposal which describes personnel 
with less than these qualifications may be considered "non- 
responsive". In order to promote continuity and stability 
throughout the length of the project, NAVDAC also encourages 
considering the contractor's response to the requirement 
that "50 percent of original contractor personnel arriving 
on a Navy site to perform a risk assessment will remain on 
site for the duration of the contract" [Ref. 32]. 

Evaluation of cost factors will generally be handled 
by the Procuring Contracting Officer of the Navy Regional 
Contracting Center. This will exclude consideration of the 
cost cf preparing the TOP, which, as is the case with 
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conventional RFPs, is done at the. expanse of the contractor. 
However, those prices which will be recognized include "all 
direct labor, overhead, general and administrative expenses, 
plus an amount for profit" [Bef. 32]. In this regard, most 
risk assessment contracts will probably be of the 
Cost- plus-fixed- fee type. 3ased on NAVDAC's general 

guidance for evaluation factors and weightings, a proposed 
Internal Score Sheet for any activity's TOP evaluation is 
included as figure 3.3 . The reasoning for the discrepancy 
between experience and past performance is as follows : 
experience in all areas listed is crucial, and while past 
performance on related contracts would certainly be a 
desired feature in a contractor, chances are that few will 
have dealt directly with risk assessments (considering that 
they are a relatively new requirement). Price factors 
should constitute about 20 percent of the total weighting. 
After the contract administrator has completed the negotia- 
tions, the selection is made, and "a finalized Task Order 
will be executed by the contractor and. the contracting 
officer" £Bef. 32]. 

B. CONCLUSIONS 

NAVE AC's recognition of the need for allowing contractor 
assistance in conducting computer risk assessments is both 
admirable and realistic. 2ven if an activity could spare 
the personnel necessary to conduct a risk assessment, there 
would undoubtedly be a lack of expertise in the necessary 
policies and procedures. At this stage of the game, where a 
risk assessment is still a relatively new and complex pheno- 
menon, few people understand what it is, let alone hew to 
conduct an assessment. (This will undoubtedly change, 
however, as NAVDAC places more and more emphasis on ADP 
Security training) . 
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Internal Score Sheet 



1. Technical Approach — weight 30 points 

a. ) Understanding of Task 

1. ) Sisk Ass9ssn?nt 0-4 

2. ) rtethcdology 0-4 

b. ) Hesponsivan* ss to specifications 

in Task Request 0-15 

c. ) Appropriateness cf approach 

1. ) Activity's environien t/ops 0-3 

2. ) Activity's coaputer configuration 0-2 

3. ) DOH-approved risk asssssient 

requireaents 0-2 

2. Experience — weight 30 points 

A.) Coaputer Canter Operations 0-3 

3.) ADP Bisk Assessaent methods 0-7 

C.) Systea Software Generation 0-3 

O. ) Coaputer Security 0-6 

2.) Telecoaaunications Security 0-3 

P. ) Coaputer Hardware and Interconnections 0-3 

G.) Clearance coaaeasurate with the highest 

level contained in the systea 0-5 

3. Past Perforaance — weight 15 points 

A.) Conducting Risk Assessaents 0-5 

3.) Perforaing ADP Security- related projects 0-10 

4. Sanageaent — weight 20 points 0-20 

5- Location — weight 5 points 0-5 



(with the understanding that 50% of the original contractor 
personnel reaain on site for the duration of the contract). 



OFFEROB : 

27 ALOATOB : 




Figure 3.3 Contractor Evaluation Score Sheet. 
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While specific details and samples of contract documents 
are available to any activity requesting them, NAVEAC 

encourages tailoring them to the activity’s needs. As top 

management, security personnel, and computer specialists 
become mere educated in the risk assessment phenomenon, the 
need for such specific guidance will dwindle. In the mean- 
time, government resources will be saved by avoiding the 
possibility of mismanagement cf contracting for computer 
risk assessments. 
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IV. A FJAMEWO RK FOR CONDUCTING A RISK ASSESSMENT AT NPGS 

The Department of the Navy Automatic Data Processing 
Security Program was recently promulgated by 

OPN A VINST . 5 239 . 1 A on August 3, 1 982. The instruction 

provides policy and guidance to commanding officers 
concerning the establishment, of local automatic data 
processing (ADP) security programs. Each command’s program 
should be designed with the goal of achieving accreditation 
by the appropriate designated approving authority (DAA) . In 
particular, each activity must develop an activity ADP 
security plan (AADPSF). This plan must be approved by the 
Commander, Naval Data Automation Command (COMNAVDAC) . The 
A ADP S P should document current security environment, estab- 
lish program objectives, and outline a plan of action and 
milestones (POAM) for security program implementation. An 
item that will be included in the POAM is the completion of 
a risk assessmemt. A risk assessment may be conducted inter- 
nally if an ADP activity has the necessary expertise 
Commercial assistance is available to conduct a risk assess- 
ment. CCMNAVDAC maintains a list of authorized contractors 
and retains approval authority for contractor selection. 

This chapter provides a framework for conducting a risk 
assessment at the Naval Postgraduate School. A framework, in 
the absence of theory, is helpful in organizing a complex 
subject, identifying the relationships between the parts and 
revealing the areas in which further development may be 
required [Ref. 35]- A risk assessment at a naval activity 
must be governed, of course, by OPNAVINST. 5239.1 a. However, 
this instruction is very broad in scope and covers the 
entire ADP security spectrum. It should be helpful to have 
the necessary steps fcr a risk assessment , applied tc the 
Naval Postgraduate School, presented in this framework. 
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A risk assessment involves a detailed examination of ail 
the aspects cf a computer system: hardware, software, data, 

procedures, etc. The use of these assets, that is, the use 
of the computer systems at the Naval Postgraduate School, 
including the IBM 3033AP system in the tf.C. Church Computer 
Center, various mini and microcomputers in Spanagel Hall, 
and independent units obtained under grant by several prof- 
essors, spans virtually all departments and includes 
faculty, students, and military and civilian staff. This 
fact implies that a significant amount of cooperation 
between different organizations will be required to success- 
fully complete a risk assessment. This endeavor requires 
command attention at upper levels to impress upon all 
concerned the importance with which the command views a 
subject cf this nature. With this understanding, a project 
cf this magnitude should produce meaningful results which 
will serve several purposes; 

1) Enable the Naval Postgraduate School to proceed 
successfully along the path to AD? security 

acc reditation . 

2) Provide documentation stating the current condition 
of security with respect to the computer systems 

at the Naval Postgraduate School. 

3) Frovide a reference for quantitatively evaluating 
security countermeasures. 

4) Frovide a platform from which improvements in 
command security posture can be built. 

A. INITIAL STEPS: PERSONNEL SELECTION AND SECURITY SURVEY 

The initial step in undertaking this project is to iden- 
tify the personnel who will participate as members of the 
risk assessment team. Expertise from various disciplines 
such as computer science, management, and admimstrat ive 
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science will be required. Personnel selection is a very 
delicate subject in the commercial environment. Dcnr Parker 
of the Stanford Research Institute (SRI), at the 1 S77 
National Computer Conference, criticized the concept of a 
risk assessment team made up of key company personnel. A 

team approach gives a relatively large number of employees a 
virtual inventory of data processing vulnerabilities. It 
may be prudent to have risk assessment team members partici- 
pate in detailed analyses only on a need-to-kncw basis. 
[Ref. 40] However, this situation will not pose a problem at 
the Naval Postgraduate School. Given the relatively tran- 
sient nature of students and staff at this institution, the 
following recommendations for staffing this project are 
proposed. The position of project manager should be 
assigned to the ADP security officer. The tasks which this 
position entails are guite consistent with the duties of the 
ADP security officer. Additionally, tha participation of 
students from the Computer Systems Management and the 
Computer Science curricula should be solicited. The 
majority of the work required in this project could be 
completed by students. The risk assessment may serve as a 
thesis project for several teams of interested students. 
Faculty members of the Computer Council could function in 
the role of thesis advisors while maintaining an active 
interest in the risk assessment process. The project could 
be broken into three distinct phases. Students partici- 
pating in these phases would build directly upon the work 
accomplished by earlier students. A proposed phased organi- 
zation might be: 

1) Security Survey, Asset Identification and Valuation 
Phase 

2) Threat and Vulnerability Evaluation Phase 

3) Computation cf Annual Loss Expectancy and Evaluation 
and Selection of Additional Countermeasures Phase 
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The fcrmal assignment of personnel to the Risk 
Assessment Team is accomplished by the issuance of the Risk 
Assessment Team Charter. The charter is generated by -he 
command itself and identifies chose personnel who ccmpcse 
the team. Since students will be participating in this 
endeavor, periodic updates to this document will be 
required. The document lists the objectives of the team and 
details the authority and responsibility of each person. 
The charter also states the products which the team is 
expected to produce. 

The next step in the overall process is to conduct an 
ADP security survey. A sample survey is listed in the ADP 
Security manual [Ref. 36]. An item which will be needed to 
ensure that the survey is complete is a listing of all ADP 
equipment located at the Naval Postgraduate School. The 
survey should encompass all equipment so that its results 
can be interpreted with seme degree cf confidence. The 
results provide an indication of the current security situa- 
tion and also may shew how much effort will be required tc 
conduct the risk assessment. It should be noted that a 
complete and accurate listing of all equipment is crucial to 
the success of the overall assessment. Failure to include 
certain equipment may invalidate any assessments made on 
ether equipment affected by missing items. The major compo- 
nents of the I3K 3033AP system are listed in an NPGS publi- 
cation, "Introduction to the Church Computer Center". Of 

course, this information should be verified prior to use in 

this endeavor. 

The vast majority of the users are not working with 

high-value data, but rather with routine, academically 

oriented material. No classified data is supposed to be 
stored on the IBM 3033AP system. Additionally, most of the 
processing done at the Church Computer Center is not in 
support of fleet operations. The results of the survey 
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indicat? some directions for the risk assessment to pursue. 
The formal results cf the survey should be compiled and 
submitted as an appendix to the risk assessment document. 

The results of the survey also impact upon the risk 
methodology selected. As the ADP Security manual states, 
"the decision (concerning which methodology to use) should 
be based on the complexity of the ADP environment. The 
complexity is governed by the level cf data processed, 
security mode of operation, ADP system configuration and 
location, and the criticality of the mission." [Ref. 37] 
There are two methodologies available. The most common 
methodology for ADP activities is listed in the Security 
manual as Methodolgy 1. This methodology appears tc be 
suitable for a risk assessment at the Naval Postgraduate 
School. Methodology 1 is the standard methodology used in 
most ADP environments and provides for suitable interaction 
between threats and losses. The risk assessment conducted 
according to methodology 1 can be divided into several 
phases as shown in figure 4.1. As previously mentioned, 
these phases could quite conveniently be assigned to 
students as thesis projects. The successful completion of 
each phase is well within the capabilities of interested 
students . 

B. ASSET IDENTIFICATION AND VALUATION 

The next phase in this process consists of asset identi- 
fication and valuation. Some crucial items of information 
are needed to properly complete this phase. As previously 
mentioned, a complete, up-to date list of all computer 
system assets is required. The Computer Council is tasked 
with maintaining an inventory of all hardware assets 
[Ref. 38]. They should be able to provide the necessary 
information in this area. Completeness and accuracy are the 
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I. 



II. 



III. 



IV. 



I ASSET IDENTIFICATION 

| AND VALUATION 



I THREAT AND 

| VULNERABILITY EVALUATION 



I 

V 



| COMPUTATION OF THE 

| ANNUAL LOSS EXPECTANCY 



I 

V 



I 

I 



I 

I 



I EVALUATION AND SELECTION OF I 
I ADDITIONAL COUNTERMEASURES 



Figure 4.1 Major Steps of Method I Risk Assessment. 

keys tc the success of the risk assessment. Otherwise, the 
possibility exists that seme piece of ADP equipment not 
listed, and sc not considered in the risk assessment, may 
sotnehew interact with equipment that is considered. The 
threat and the associated loss may invalidate the assess- 
ments made previously on related equipment. 

The ether elements crucial to this phase are the impact 
value ratings. The risk assessment team will determine the 
impact value ratings. The ADP Security manual gives seme 
general guidance for assigning these values. Since the 

major purpose of a risk assessment is to provide a quantita- 
tive base for evaluating the cost-effectiveness of counter- 
measures, the importance of these values cannot be 

overstated. Primary input for the values associated with 
hardware and software can probaoly be provided by th- 
ee mpu ter center staff. 
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There are four types c £ impacts for which each asset 
mas- he evaluated. These impacts are: 

1) Modification 

2) Destruction 

3) Disclosure 

4) Denial of service 

The ADP Security manual provides a concise definition of 
these impacts. Each asset must be evaluated with respect to 
these items. If an impact affects an asset, then a monetary 
value reflecting that effect should be assigned. The impact 
value rating is associated with the monetary value. This 
stage will require close coordination between the students 
evaluating the assets and those members of the team who 
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Figure 4.2 Sensitive Data Value Guidelines. 

determine the asset impact value ratings. The AD? Security 
Manual provides guidelines for the impact of disclosure of 
sensitive data. These values are listed in figure 4.2. 

There are standard forms which should be used to record 
the asset impact and valuation studies. The appropriate 
form for this phase is designated OPNAV 5239/7. An example 
of this form is provided in Appendix I. 
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C. THREAT AND VOLNEBABILIT I EVALUATION PHASE 

The next phase in the risk assessment process is The 
threat and vulnerability evaluation. According to -he meth- 
odology, all threats must be evaluated to estimate how often 
a "success f ul " attack may occur. By definition, a 
"successful" attack is one that results in a definite 
adverse impact on the activity. 

This phase will also reguire a great deal of communica- 
tion between the members of the risk assessment team and the 
staff of the computer center. For certain threats such as 
power outages, the frequency rating could oe determined by 
examining historical data. However, input from the computer 
center staff may prove valuable when attempting to determine 
frequency ratings for threats which are highly technical, 
such as errors in the operating system software. Each 
threat must be evaluated with respect to the same four 
impact areas as the assets, that is, modification, destruc- 
tion, disclosure, and denial of service. For certain 

threats which have never, and hopefully will never, cccur 
there may be some difficulty in assigning threat frequen- 
cies. There is no sound statistical base for assigning 
probabilities to human behavior problems. One method to 
approach this prcblem is to use the Delphi technique. This 
method involves having different iniividuals evaluate a 
particular probability several times to reach a consensus. 
This technique should provide a probability estimate which 
may offset the lack of a human experience base. [Ref. 41] 

A great deal of time and effort will be required during 
this phase. The more imagination which is applied tc devel- 
oping the threats and their potential adverse effects, the 
more accurate the final risk assessment will be. As a 
result, the product will serve its purpose and hopefully 
enhance ACT security. 
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The ADF Security manual provides a list cf several 
example threats. However, this list is certainly not all 
inclusive. Threats which are particular to the Naval 
Postgraduate School computer system, such as the vulner- 
ability cf the back-up power supplies and its location on 
the flight paths of the Monterey County Municipal Airport 
must be considered . The scope of this risk assessment is 
all-encompassing. Much imaginative thinking will be 
required during this phase of the undertaking, however, the 
payoff in terms cf usable output should make it worthwhile. 
The threats should be defined to minimize overlap. The 
reason for this concern is generated by the method of 
computing the annual loss expectancy, which will be 
addressed in the next step of this phase. 

The threat and vulnerability evaluations should also be 
documented on standard forms. An example of this form, 
OPNAV 5239/8, is enclosed in Appendix I. The information 

that should be described for each threat includes a general 
narrative about the threat. Examples of the threat should 
be listed and any counter mea sures which are currently in 
effect should be noted. Also, any unique circumstances of 
the command which might contribute to the threat should be 
discussed. 

As with th a previous phase, this portion of the risk 
assessment could alsc serve as a thesis project. Again, 
however, it must be emphasized that close coordination 
between the risk assessment team and the computer center 
staff is necessary to ensure that every potential threat is 
considered and that every frequency rating represents a 
realistic estimate. 

After completing the asset valuation and threat evalua- 
tion phases, the next step is to compute the annual less 
expectancy values (AIE) . This step provides the quantita- 
tive results which will be used to evaluate addititonal 
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security measures. The ADP Security manual describes a 
mechanical, fairly straight-forward procedure to determine 
these figures. The impact dollar value ratings and the 
successful attack frequency ratings interact to produce an 
annual loss expectancy figure for each of the fcur impact 
areas. The individual ALE values for each asset in an 
impact area and the individual ALE values for each threat in 
an impact area should be added to produce a total ALE value 
for each respective impact area. Summing the ALE values 
ever the fcur different impact areas results in the total 
ALE value for the system. 

As stated in the AD? Security manual, the ALE "repre- 
sents a quantitative estimate of the potential average 
yearly financial less resulting from the modification, 
destruction, disclosure of data, or denial of services 
because cf existing vulnerabilities which may permit identi- 
fied threats to be realized." [Bef. 39] One car. see that 
the types of results which are derived, namely, quantitative 
figures cf annual less expectancy, are based totally upon 
the estimates made in earlier phases. For the ALE figures 
to be meaningful, it is clear that a great deal of care must 
be taken to develop reasonable asset valuations and impact 
area dollar ratings. Also, the threat evaluation and 
successful attack frequency must be consistent and net exag- 
gerate any particular area without justification. 

D. EVALUATION AND SELECTION OF ADDITIONAL COUNTERMEASURES 

After the annual less expectancy values have been calcu- 
lated, the evaluaticn of additional countermeasures can be 
conducted. The procedure involves determining whether the 
additional countermeaures would benefit the overall security 
posture and result in a decrease in the annual loss expec- 
tancy value. Cost-effectiveness is the criteria for 
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decision-ala king when considering any additional countermea- 
sures. Essentially, every countermeasure must be evaluated 
to determine if the reduction in the ALE is greater than the 
cost of installation and implementation. Countermeasures 
may be directed against specific threats. Some software 
countermeasures include the establishing of audit trails, 
the use cf unigue password/authentication processes, and the 
imposition cf some type of residue control to clear sensi- 
tive information which the operating system allows to remain 
in resource sharing storage. Seme hardware countermeasures 
include the emplcymentof protection state variables, memory 
protection mechanisms, and the use of interruption resistant 
power supplies. These are merely a few examples of counter- 
measures which can be utilized to improve security. They 
may be such that the successful frequency attack ratings in 
several impact areas are affected. 

The procedure for evaluating additional coun ter measures 
consists of six steps: 

1) Countermeasures which can reduce the vulnerabilities 
cf those assets which currently have the higher annual 
loss expectancy values should be considered first. 

2) The vulnerabilities which would be reduced or elimi- 
nated by implementing additional countermeasures should 
be identified. 

3) Assuming that the countermeasure is implemented, the 
projected successful attack frequency ratings for each 
area should be listed. 

4) A projected ALE for each threat affected by the 
countermeasure should be calculated by impact area. 

5) The projected ALE should be subtracted from the 
current ALE to show the savings possible by imple- 
menting the proposed countermens ur e . 

6) The ALE savings in each impact area should be summed 
and then divided by the annual cost of the countermea- 
sure tc get the Ret urn -on-investment (EOT). [Hef. 42] 
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Again, there is a specific form provided to perform these 
calculations. An example of this form, OPNAV 5239/10, is 
given in Appendix I. 

The 5er.urn-cn-Invesr.ment figure is important in the 
selection of which additional countermeasure to implement. 
This selection process occurs in an incremental fashion. As 
countermeasures are implemented, they affect the overall 
security posture of the entire computer center. This effect 
is realized in a different ALE value. Since changes in the 
ALE will cause a corresponding change in the ROI for a 
particular countermeasure, the countermeasures must be 
considered singly. 

The countermeasure with the highest ROI :s considered 
first. Then, the countermeasure with the next higher ROI is 
evaluated with the new ALE resulting from implementation of 
the previous countermeasure. This procedure is continued as 
long as the respective ROI remains greater than one. The 
countermeasure s with ROI's greater than one may be ranked 
according to their respective values. A plan to implement 
these countermeasures, within budgetary limitations, may 
then be determined. 

The situation may occur where higher authority directs 
that certain countermeasures be implemented. In that case, 
these countermeasures may take priority for implementation 
regardless of their 5CI. 
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V. AD TOM AT ED VS. MAN UAL RISK AS SES SMENT SYSTEMS 
A. GENERAL 

At this time, no automated cr computerized risk assess- 
ment methodology has been approved for use by agencies of 
the Federal Government. This is no reflection on the 
Government's lack of interest or distrust in the product; it 
is more a matter of an extremely limited market - there are 
less than a handful of risk assessment software packages 
currently available. 

One of the few companies in private industry involved in 
developing risk assessment software is Pansophic Systems, 
Inc., based in Oak Ercok, Illinois. Among the software 
security products the company offers are ; Panaudit, a tool 
that can be used for ADP, financial, and statistical 
auditing cf computer systems; Panexec, which can be used for 
auditing, control, backup, and recovery measures; and 
Panrisk, an automated risk assessment system for management 
planning. Advertisements for Panrisk boast that it is 
"...the first system ever to show where to direct your 
computer security efforts with quantifiable certainty" 
[Ref. 43]. 

Although the Panrisk system works under the same basic 
framework as the manual methods advocated within the DOD, it 
has a major drawback that greatly limits its usefulness and 
applicability to government computer facilities. It is only 
compatible with I3M operating systems. However, if Panrisk 
had shewn any degree of success in the market, ether 
computer vendors would have undoubtedly developed similar 
systems for Honeywell, Burroughs and others. 
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According tc its advertising brochure, "Basically, 
Panrisk is the application of a simple formula to a variety 
of threats whose results are aggregated to give a complete 
picture cf an organization's total loss potential over a 
period of time " [Bef. 43]. The simple formula for calcu- 
lating the Annual Less Expectancy ALE is the same as that 
given in FIPS PUB 65, although the terminology used differs 
somewba t : 

ALE = single occurrence loss x occurrence rats 
ie. impact x frequency 



Skeptics might rightfully question using a computer 
system for such a calculation. Panrisk does, however, 
produce outputs beyond a simple ALE - it can format, edit, 
and generate various reports on risk information to be used 
at all levels within an organization. Tnus the package may 



have seme merit 


in its use as a 


Management Inform 


at ion 


System (MIS) or 


as a Decision Suppo 


rt System (DSS) . 


The 


problems, though 


, arise in the input 


requirements. In 


or dsr 


for the system 


to become useful. 


the organization 


must 



provide the information on its computer resources, threat 
probabilities, vulnerabilities, and loss potentials. The 
provision of such inputs constitutes the most difficult part 
cf conducting a risk assessment. Since such inputs are 
largely based on intuition and experience, it could net be 
expected that an automated system would be able to produce 
them. In general, therefore, the market for an automated 
risk assessment will be extremely limited. In the fall of 
1982, Panrisk was taken off the market for an indefinite 
period of time. 

In short, an autemated system is no better than a manual 
one on the input side of the Bisk Assessment process. 
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Furthermore, organizations must exercise caution in consid- 
ering buying off-the-shelf Risk Assessment software, since 
Risk Assessments, by their very nature, must be uniquely 
tailored to an agency's needs. From the standpoint of a 
CSS, however, an automated Risk Assessment could greenly 
facilitate a user's understanding and ability to handle 
budgeting and security problems. 

B. A RISK ASSESSMENT AS A DECISION SUPPORT SYSTEM 

An automated Risk Assessment could serve as an excellent 
application for a Decision Support System (DSS) . According 
to Sprague and Carlson [Ref. 44] the characteristics of an 
effective DSS include : 1.) Support for unstructured (or 

semi structured) problems; 2.) Support for all levels of 
decision-making; and 3.) a combination of analytical techni- 
ques and data presentation techniques. A Risk Assessment 
application should include all of these characteristics. 

Sprague and Carlson [Ref. 44] discuss three components 
that make up a DSS ; 1.) the dialog model, which serves as 

the user interface to the system; 2.) the data model, which 
controls and monitors the system data bases via a data base 
management system (DEKS) ; and 3.) the modeling component, 
which interfaces with the data ar.d dialog models to perform 
mathematical and analytical operations. 

The dialog component of a DSS is perhaps the most impor- 
tant since, from the user's point of view, it functions as a 
virtual system. The dialog component must be able to 
support a variety of presentations and output devices, 
different inputs, dialog styles and communications, and 
above all, must be user friendly. [Ref. 44] For a Risk 
Assessment application, this means that the user (possibly 
the command's Security Manager or ADP Security Officer) 
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should be able tc select the way in which he inputs tc the 
system and the way in which outputs are displayed on the 
terminal or printer. Inputs, which may include keyboard 
inputs, joysticks, function keys, etc., will be constrained 
by the available hardware, but outputs can have several 
options, largely software-supported, which will only be 
constrained by the user's and builder's imaginations and 
abilities. Users may request that the dialog conventions 
used include guesticr./answer sessions, menu selections, 
graphical displays, and HELP facilities to aid in supporting 
the user's knowledge base. 

The data component should be able to support a variety of 
data structures and types, while allowing for easy data 
access and retrieval [Ref. 44]. This will require an 
extremely versatile and capable DESS, but the current 
state-of-the-art is such that these requirements could be 
met by a system as simple as DBASE II which is available on 
most microcomputers. The DBMS of a Risk Assessment applica- 
tion will require that the user be provided capabilities tc 
generate, update, and maintain data bases composed of, at a 
minimum, threat, asset, and vulnerability information. 

The modeling component must provide a Model Base 
Management System (MEMS) to allow for the building and crea- 
tion of new models, model manipulation, and the management 
of a library of models [Ref. 44]. The models in a Risk 
Assessment CSS will be used to calculate ALZs for impact and 
threat categories, compare various ALEs, and mathematically 
combine and manipulate ALE figures. This component could be 
handled by the programming capabilrties of DBASE II. 
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DESIGN SUGGESTIONS FOR A DECISION SUPPORT SYSTEM 



1 • The Pi a 1 eg Cc acons n t 

This component should initially allow the user 
several presentation options, and should be built such that 
later refinements and enhancements can be made with relative 
ease. As the user becomes familiar with the system and 
feels comfortable in using it, he may want to reduce the 
system’s HEIF facilities in favor of more speed and flexi- 
bility. Initially, however, the user's knowledge base will 
be small and he will prefer to be "led through" tne system. 
Assuming the user is at least familiar with how to 
initialize the system, turn the terminal on and logon, he 
will then need to know how to make a call to the Sisk 
Assessment DSS. This should be as simple a type-in as 
"Begin Risk", "Co Risk", or "Risk" followed by a carriage 
return. Ihe initial screen might look like the one shewn in 
figure 5.1. An additional option might involve moving a 
cursor eelew the desired operation using a joy stick, or 
selecting the operation with a light pen. Once an operation 
is selected, a new screen showing additional options within 
that operation will be displayed. Ail screens beyond the 
initial one will provide "Help" options as well as options 
to return to the main menu or end the session. The dialog 
model might also present the user with a canned list of 
assets, threats, and vulnerabilities, such that he could 
delete those that were inapplicable to his organization, and 
add those that did apply. This would not only serve to 
increase his knowledge base, but would also prevent a lot cf 
unnecessary terminal work. 

Cutput representations from the operations should 
come in a variety of formats. Bar graphs might prove to be 
desirable representations since the user may want ccmpari- 
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RISK ASSESSMENT DSS 

Select the desired operation by typing the corresponding 
number followed by a" carriage return. 

1. ) Database Update/Modi ficaticn 

2. ) Display a list of computer system assets 

3. ) Display a list cf computer threats 

4. ) Display a list cf computer vulnerabilities 

5. ) Calculate Annual Loss Expectancy (ALE) values 

6. ) End Session 

WAITING : 

I I 



Figure 5.1 Initial Screen for a Risk Assessment DSS. 

sons cf various ALEs at different periods of time. Figure 
5.2 illustrates the type of output representation that might 
be provided by a Risk Assessment DSS. Similar output repre- 
sentations could be constructed for the other impact areas 
as well as for threats, assets, and vulnerabilities. For a 
DSS cf this type, most users will desire outputs that show 
comparisons of relevant information. A prioritized list of 
vulnerabilities, for example, would show which vulnerabili- 
ties are the most ccstlv in terms of ALEs. 

2 • The Data Comp onent 

The Data Component will be perhaps the most diffi- 
cult to understand and manage. A viable and capable Data 
Base Management System (DBMS) will be required to maintain 
the vast number of files, the large sizes cf the files, and 
the links between the files. In general, an effective DBMS 
should result in reduced costs of building and using the 
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NOTES: The ALE OF $60K in 1979 represents the value 
calculated for the completion cf the original ALE. 

Due to the addition of the High Speed Communications 
System in 1980, the increase m system vulnerabilities 
brought about a proportionate increase in the ALE (tc 
$ 80KJ . 

Installed countermeasures lowered the ALE TO S50K in 
1981. Ihis status was retained through 1982. 

Existing plans should decrease the ALE TO $45K by 1983. 



Figure 5.2 Bar Graph Output Representation. 

DSS, increased data control and sharing, and reduced data 
redundancy. [Ref. 45] In building the D3HS for a DSS, the 
designer will chose a data model, whren is a "method of 
representing, organizing, storing, and handling data in a 
computer" [Ref. 46], The three parts comprising a data 
model include : 1.) a collection of data structures; 2 .) a 

collection cf operations that can be applred tc the data 
structures; and 3.) a collection of integrity rules that 
define the valid states for the structures. [Ref. 46] 

The data structures for a Risk Assessment will vary 
depending cr. the type of file. Separate files will, at a 
minimum, be required for computer assets, threats, and 
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vulnerabilities. Figure 5.3 shows the fields than might be 
contained in such files. Such a field structure, however, 
will obviously result in a great deal of data redundancy. 
For example, one asset will be exposed to several threats; 
conversely, one threat may affect several assets. The most 
wasteful method would be to list every threat affecting a 
specific asset and include them as part of a record in the 
asset file. Similarly, every asset affected by a specific 
threat wculd be included as part of a record in the threat 
file. A more logical method of constructing these files 
would be tc link the records in each file together using 
some type of relational data base model with primary and/or 
secondary keys. 

Siithin the data model it will be necessary tc defrne 
a relationship between the asset and threat files such that 
it can be determined which assets are affected by which 
threats, and within which impact categories. The fields 
used for this relation will be the Id? ACT CATEGORIES (4 ) in 
the asset file, and the IMPACT CATEGORIES AF? ECT ED ( 4 ) in the 
threat file. By defining this relation, it will be possible 
tc select a specific asset, link it to an applicable threat, 
and calculate the ALE. This type of linkage could be 

performed by a JCIN operation. According to Kroenke, "The 
JOIN operation is used to combine two relations. A value of 
one attribute in the first relation is compared with a value 
of an attribute in the second. If the two values have a 
relationship specified in the join operation, then the 
tuples of the relations are combined to form a third rela- 
tion.” [Ref. 50 ] Thus, an asset record and a threat record 
can be "joined” by issuing a command such as; 

ASSET (IMEACT CATEGORY (4) =IMFACT CATEGORY (4) AFFECTED) THREAT 
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CATEGORY field in 



where the value of the IMPACT CATEGORY field in the asset 
file is compared to the IMPACT CATEGORY AFFECTED (4) field in 
the threat file. If the values of the two fields are egual, 
then the two records can be combined tc form a single 
record. In this way, it can be determined that the record 
resulting from the JOIN operation contains an asset, an 
applicable threat from a specific impact category, and the 



i 1 



ASSET FILE : 

asset r.ame/asset categor y/descript ion/impact categories 
(4)/impact category costs(4)/ 

THREAT FILE: 

threat name/description/imtact categories affected (4)/ 
frequency of occurrence/ 

VULNERABILITY FILE: 

vulnerability name/descr ipt ion/t hr eats exploiting/ 
COUNTERMEASURE FILE: 

countermeasure name/descriotion/cost of implementing/ 
vulnerabilities a ffectin g/ihrsat frequencies 
affecting/ 



Figure 5.3 Field Layout for Required Files. 

frequency of occurrence for that threat. The ALE can then 
be calculated by multiplying the impact value times the 
threat prcbability. 

The operations that will be applied to the data base 
files shculd include, but not necessarily be limited to, 
retrieval, update, modification, combination, and summaticn. 
The dialog component should prompt the user for the desired 
operation, while allowing him tc specify such details as 
file name, field name, etc. 

The integrity rules for the field values in the 
files may be kept relatively simple. Values for impact 
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category may easily be constrained to the four categories of 
destruction, modification, disclosure, and denial-cf- 
service. Numeric values may be limited to a relatively wide 
range of values within certain limits. For example, 
frequency ratings for threats may contain any decimal value 
between .COO and .999. ALE values for the destruction cate- 
gory will be equal to the asset replacement cost. By the 
same token, no asset ALE may exceed its total replacement 
cost . 

3 . The Mo d e 11 n q C om pon en t 

"The modeling component is the primary tcol for 
supporting many of the activities that decision makers will 
perfcrm in the process of making decisions and solving prob- 
lems” [Ref. 47], The decisions and problems for a Risk 
Assessment application will evolve about the calculation of 
ALEs, and determining the areas where the greatest ALE 
reduction can occur. Thus, a library of models, consisting 
cf permanent, ad hcc, user-built and "canned” models 
[Ref. 47] will have to be made available to the user. The 
permanent mcdels, these desired by most users, might have 
the capabilities shewn in figure 5.4. In addition to these, 
model generators should be at the disposal of the users in 
order that they may generate and structure their own models. 
Optional models that may be requested involve activities for 
projection, deduction, analysis, creation of alternatives, 
comparison of alternatives, optimization, and simulation. 
[Ref. 48] 

4 . In tegr a tion cf Como o nent s 

"The modal base and its management system must be 
integrated with the dialog directly, to give the user direct 
control ever the operation, manipulation, and use of models” 
[Ref. 49]. 3y the same token, there must be a tight 
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THREAT MODEL : 

a “calculate, on , summation , and analysis of the ALEs 
contributed to by specific threats 

ASSET KOCEL : 

tlie Ills attributed to specific assets. 



VULNERABILITY MODEL : 

an analysis a nl~ perce nta g e calculation of the ALEs 
caused by specific vulnerabilities. 

COUNTERMEASURE MODEL : 

an“analysis oT EailLE reductions that might be broucht 
about by the implementation of specific countermeasures. 
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Figure 5.4 Permanent Model Capabilities. 



coupling between the modeling component and the data compo- 
nent. "With this direct linkage, models can be updated as 
the data values are updated, and modified or restructured 
when the data have changed enough to require it" [Ref. 49]. 
The components and the possible linkages among them may be 
depicted as in figure 5.5. 
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Figure 5.5 Integration of DSS Components. 



0 



LIMITATIONS 



The construction and design of the dialog and modeling 
components can be made with relative ease. It ns in the 
design and development of the data component that the 
majority cf the difficulties will arise. This will create 
additional problems in that a complete and capable DBMS is 
critical tc the correct functioning of the dialog and 
modeling components. The DSS can not function without the 
complete integration cf the three components. 

The user is also confronted with severe difficulties in 
the actual construction of the databases. While the 

designer may be able to provide an efficient mechanism 
through which databases may be created and updated, the user 
may be frustrated in his attempts to collect the data needed 
tc include in the databases. 
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VI. CONC LOST ONS AND REC OM MEN DATIONS 



This thesis has examined various facets of “he concepts 
of risk assessment. The subject is exceedingly complex and 
affects virtually all segments of organizations which employ 
computers tc accomplish their objectives. The multitude of 
directives promulgated by various agencies of the federal 
government attest tc the attention being focused cn risk 
assessments. The quality of the direction provided in this 
area is generally good; however, the instructions are often 
lengthy and sometimes written in a style difficult to 

follow. The most important point expressed in Chapter Two 
is the realization that competent guidance concerning risk 
assessments exists. The level of user awareness regarding 
the availability of this guidance must be raised. As the 
federal government in general, and the Department of the 
Navy in particular, allocate more and more funding to 
computer systems resources, organizational dependence upon 
computer services will grow. This fact necessitates a 

corresponding effort towards ensuring the security of 
computer systems. For example, the Naval Regional Data 
Automation Center, San Francisco (NARDAC-SF) allocated 
several personnel in its Management Control Department to 
conduct a risk assessment at that facility. Their study 
resulted in a total annual loss expectancy for NARDAC-SF 
amounting to over S3. 8 billion. It should be noted that an 
astronomical figure like 3 8.8 billion in no way represents 
the actual expected value of losses during a given year. 
Rather, it is the aggregate ALE resulting from totalling the 
individual ALE’S in each impact area. These figures indi- 
cate the relative priorities to be placed on security 

measures in different areas. Clearly assets evaluated at 
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relative sums of this magnitude warrant significant security 
appraisals. This attention and analysis is precisely the 
driving influence behind the risk assessment directives. 
Further dissemination to the proper individuals with appro- 
priate authority should increase security efforts in this 
area . 

Several aspects associated with contracting fcr risk 
assessment services were considered in Chapter Three. 
0PNAVINS1. 5239. 1A directs all commands with computer system 
assets to conduct a risk assessment. The amount of effort 
required to conduct a risk assessment may force smaller 
commands to seek outside assistance. Naval Regional Data 
Automation Centers (NfiRDACS) are available to provide assis- 
tance. However, the various NARDAC's around the country are 
staffed at different manning levels, so the amount of assis- 
tance each command is able to provide may vary. CCMNAVDAC 
maintains a list of contractors approved to conduct risk 
assessments or to provide assistance to commands conducting 
their own risk assessments. 

As the framework for conducting a risk assessment at the 
Naval Postgraduate School demonstrates, the task of actually 
conducting cne is certainly non-trivial. Compiling a list 
of all systems assets and procedures and assigning impact 
values tc them is a complicated , t ime-ccnsuming endeavor. 
Of equal difficulty is determining a list of all potential 
threats and their associated frequency ratings. It requires 
personnel experienced in the areas of computer operations, 
finance and administration. The computation of the annual 
loss expectancy and its use in evaluating the potential 
benefits cf countermeasures is also an effort which requires 
a great deal of precision and judgement. The ADP Security 
Manual provides a reasonably clear explanation of these 
steps and good background material which is beneficial. The 
manual alsc provides examples for each type of computation. 
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In general, the emphasis currently being devoted to 
security and risk assessments in the Navy is very timely and 
prudent. Given the dependence of the Navy on computer tech- 
nology for such services as supply processing, tracking 
spare parts failure and usage rates, environmental fore- 
casting, payroll and personnel records and a myriad of ether 
tasks, it is easy to imagine the havoc which could be 
created if these services are disrupted. The risk assess- 
ment program is a positive effort to study the state of 
security with respect to a command's computer systems, 
quanitfying the assets and threats and using this data to 
evaluate countermeasures. The criteria for evaluating coun- 
termeasures is cost-effectiveness. The risk assessment 
procedure appears to be a logical manner in which tc deter- 
mine the relative impacts cf various threats on system 
assets utilizing this criteria. 

It would be difficult, if not impossible, to quantify 
the exact value of the risk assesment itself. Since the 
overall purpose cf a risk assessment is to justify counter- 
measures in order to prevent disasters, hopefully potential 
disasters will be averted. Certainly attention will be 
directed tc problem areas in security. However, even though 
this process has net been quantified, the logic providing 
the impetus to conduct such assessments seems well-grounded. 

No procedure in this area, however, will be successful 
unless if receives a sufficient amount of command attention. 
The general tendency for most commands is to treat the 
security and reliabiltiy of computer services in a "taken- 
for-granted" manner. The magnitude cf the potential 
disasters due to the loss of computer services makes a 
change in this type cf care-free attitude imperative. The 
requirement directing all commands with computer systems to 
conduct a risk assessment is an important, liable means of 
correcting this attitude. It forces commands to make a 



82 



rational, thoughtful analysis of its systems as directed by 
0PNAVINS1 5239. 1A. To derive maximum profit from this 
procedure, the command should ensure that all concerned 
personnel are aware of the significance of conducting this 
exercise. If the risk assessment procedure degenerates into 
a "paperwork drill" conducted by some personnel in the lower 
levels of the command, then the results may be virtually 
wort hless. 



A. SOGGESTIONS/RECOMMENDAT IONS FOR IMPROVEMENTS 

As mentioned previously, the risk assessment at the 
Naval Postgraduate School can be completed by students in 
the various Computer Systems and Management curricula. This 
situation would provide many benefits of both an academic 
and practical type, net the least of which are: 

1) Provide participating students with a fundamental 
knowledge of the computer security problem. 

2) Save the Naval Postgraduate School a consideraole 
amount of money. 

The remaining recommendations are directed at the larger 
scale problem. A measure which would improve both the effi- 
ciency and effectiveness of the risk assessment procedure 
might be to establish assist teams at NARDAC's throughout 
the country. These teams would be availaols to assist 
commands desirous of conducting risk assessments by 
providing expertise in security areas not normally encoun- 
tered by activities as part of their normal routine. The 
establishment of these teams would serve several purposes: 

1) Provide a body of experts to conduct risk 
assessments and/cr to provide assistance to 
commands conducting them. 

2) Enable commands throughout the Navy to conduct 
their own assessments without being forced to 
contract for services. 
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Another area which could be improved is to provide more 
definitive guidance to commands concerning the value of 
systems assets. Central agencies in Washington, D.C. such 
as the Automatic Data Processing Selection Of f ice ( ADPSO) and 
the Naval Data Automation C camand (N A VDAC) maintain approval 
authority and inventories of major systems throughout the 
Navy. These agencies should possess daza concerning the 
costs of various types of hardware, software, and possibly 
data. The dissemination of this daza could eliminaze seme 
cf zhe estimating reguired to get values for systems assezs. 

A final recommendation concerns the subjecz cf an auzo- 
mated risk assessment package. Chapter Five has presented 
the preliminary design for a Risk Assessment Decision 
Support System. A feasibility study, conducted perhaps az 
one of the NASDAC’s, might be undertaken to assess whether a 
DSS of this type would be beneficial and cost-effective on a 
Navy-wide basis. To satisf $ a wide range of users, this DSS 
would have to be extremely user-friendly and capable of 
accepting a variety cf inputs. It may be that the inventory 
cf Navy computer systems is so varied that this type of 
management support aid would not be practical on such a 
large basis. However, the potential benefits cf this tool 
merit seme investigation. 
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APPENDIX A 

EXAMFLES OF 7ARI00S FORMS USED IN RISK ASSESSMENT 

COMPUTATIONS 

This is an axampls of OPNAV 5239/7. 



uwrn. ami 

ASSET VALUATION WORKSHEET 

I ASS£t name 



2. ASSET DESCRIPTION ANO JUSTIFICATION OF IMPACT VALUE RATINGS A3SIGNE0. 



I 



! 



t 

i- 



3^ impact value rating by impact area *"* { 

Q modification Q destruction 0 DISCLOSURE . □ denial df service j 

OPNAV 5239/7 (2-92) 
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This is an 



axaaple of OPNAV 



5239 / 8 . 



. QPWAV1HJT jSlSJi 

THREAT AND VULNERABILITY EVALUATION WORKSHEET 

' I. THREAT NAME 



Z. DESCRIPTION, EXAMPLES, AnO JUSTIFICATION BASED ON EXISTING COUNTERMEASURES AND VULNERABILITIES. 



1 



I 



I 

i 

I 

1 

i 

j 



3. SUCCESSFUL ATTACK FREQUENCY RATING BY IMPACT AREA. 

| | MODIFICATION | | DESTRUCTION | [ DISCLOSURE Q DENIAL OF SERVICE 

OPNAV 5239/9 (2-92) 
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This is an -example of OPNAV 5239/10 



OPNAVINST 5239-1/1 



additional countermeasure evaluation worksheet 



I. ; uNTERMEASURE NAME 



2. ANNUAL COST 



THREATS AFFECTED ST THIS COUNTERMEASURE 



5. 

W 



ALE 



CURRENT 



(IN 



PROJECTED 



S. 



ALE SAVINGS 



l 



1 7. RETURN ON INVESTMENT 

I 

9- OVERLAPPING ADDITIONAL COUNTERMEASURES 



OPNAV 3239/10 (2*92 J 



8. TOTAL 
ALE 

SAVINGS 
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